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(§)Verfahren zum Laden eines Doppelrechner-Standby Systems 

(g) Verfahren zum Laden eines Doppelrechner-Standby-Sy- 
stems nrrit neuer Anwendersoftware, wobei die beiden 
Rechner uber einen intemen Datenkanat miteinander ver- 
bunden und jeweiis uber einen extemen Datenkanat mit 
einer extemen Oatenquelle verbindbar stnd und jeweits uber 
ein Multitaskingbetriebssystem verfugen. mit einer Obenva- 
chungseinhett, durch welche die beiden Rechner wechsel- 
seitig in einen aktiven bzw. passiven Zustand geschaltet 
werden konnen. gekennzeichnet durch die Schrttte Vorberei- 
tung des passiven Rechners auf das Laden, Laden von etner 
externen Datenquelle aus uber den extemen Datenkanal. in 
den aktiven Rechner und von dort uber den intemen 
Oatenkanal in den passiven Rechner. nach Ende des Ladens 
Starten des passiven Rechners und Umschattung desselben 
in den ~ aktiven ' Zustand. wenn '~neue Anwendersoftware 
faiHos. 

■ AnschlieGend Laden des jetzigen passiven Rechners von 
h dem aktiven Rechner uber den intemen Datenkanat. Keine 
Unterbrechung oder Beeintrachtigung des taufenden Be- 
^ trtebs durch das Laden. Ruckladefndglichkeit der alten 
I Anwendersoftware, wenn neue Anwendersoftware fehler- 
haft. 
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Beschreibung 
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Die Erfindung bezieht sich auf ein Verfahren zum 
Laden eines Doppelrechner Standby-Systems gemaB 
Oberbegriffdes Anspruches 1. . 5 

In dem US Patent 43 71 754 wird ein automausches 
fehlerbehebendes Rechnersystem beschrieben, in dem 
aktive Speicherbereiche an Siandby-Speichem geladen 
werden und zwischen aktiven und Standby-ICopien um- 
geschaltet wird. Dieses dient zur Fehlererkennung und lo 
Fehlerbehebung im laufenden Betrieb. 

Der Aufsatz -Oneline-Software-Erweiterung und 
-Anderung" von U. Apel in Elekirisches Nachrichtenwe- 
sen Band 64 Nr. 4 von 1990 (Seite 327-333) beschaftigt 
sich hingegen mit dem Laden eines Rechners mix gean- 15 
derter oder erweiterter Software, wobei die beiden Fal- 
le unterschieden werden, ob die alte und die neue Soft- 
ware parallel laufen konnen oder nicht. 1st ersteres der 
Fall, so konnen die neue Komponente gestartei und 
Nachrichten an beide Komponenten gerichtet werden, 20 
wobei der Verkehr zu der neuen Komponente allmah- 
lich erhoht werden kann, bis die alte Komponente kerne 
neuen Nachrichten mehr erhalt und entfernt werden 
kann. Dieses Verfahren erfordert einen sehr groflen 
Speicherbedarf. 25 

Wenn die alte und die neue Komponente nicht paral- 
lel laufen konnen, so werden die alte Komponente auf 
die Funktionserweiterung vorbereiiet und der erforder- 
liche Zustandsiransfer durchgefuhrt. wobei beim Errei- 
chen vordefinierter Synchronisationspunkte angehalien 30 
Oder geendet wird und alle Nachrichten zur neuen 
Komponente umgeleitei werden, die dann gestartet 
wird, wonach die alte Komponente schlieQlich beendet 
und entfernt wird. Bei diesem Verfahren ubernimmt die 
neue Komponente sofort den gesamien Verkehr. 35 

Nachieilig ist hierbei die Unterbrechung des laufen- 
den Betriebs beim Laden der neuen Anwendersoftware. 

Bei beiden Verfahren ist auQerdem nachteilig, daB em 
fehlerhafter Ladevorgang oder das Laden einer nicht 
ablauffahigen Anwendersoftware zum Systemausfall 40 

fuhrt . . . 

Der Erfindung lag die Aufgabe zugrunde. em Verfah- 
ren der eingangs genannten An anzugeben, welches m 
der Lage ist, eine Anderung oder Erweiierung der An- 
wendersoftware ohne Unterbrechung des laufenden Be- 45 
triebes in unaufwendiger Weise durchzufQhren. AuBer- 
dem soli ein fehlerhafter Udevorgang oder das Laden 
einer nichtablauffahigen neuen Anwendersoftware 
nicht zum Systemausfall fuhren. 

Diese Aufgabe wurde gelost durch die Merkmale des 50 
Anspruches 1. Vorteiihafte Ausgestaltungen ergeben 
sich durch die Unteranspruche. Das erfindungsgemaOe 
Verfahren weist die Vorteile auf, daB das Laden neuer 
oder erweiterter Anwendersoftware ohne Unterbre- 
chung Oder Beeintrachtigung des laufenden Betriebes 55 
ermoglicht wird. Der Ladevorgang erfolgt uber den ex- 
lernen Datenkanal im fehlerfreien Obertragungsfatle 
nur ein einziges Mai. so daB die exteme Datenquelle. 
welche die neue Anwendersoftware liefert und der ex- 
teme Datenkanal nur minimal belastet sind. Diese Bela- eo 
stung wird noch weiter reduziert. wenn ledigUch die 
Anderung der neuen Anwendersoftware ubenragen 

wird J- 7 • 

Wenn zum Laden des passiven Rechners die Zwi- 
schenspeicherung der zu ubertragenden Anwendersoft- 65 
ware im Arbeitsspeicher des aktiven Rechners block- 
wcisc Oder in einigen Blocken erfolgt, so ist auch die 
Anforderung an die Speicherkapazitat der beiden Rech- 



ner nur minimal oder unwesentlich groBer. 

Nach Beendigung des Ladens des passiven Rechners 
wird die neue Software gestartet, und der Diagnose- 
rechner oder eine sonstige Oberwachungseinheit kann 
dann feststellen, ob die neue Anwendersoftware fehler- 
frei ist oder nicht. Sofern ein Fehler vorliegt, kann ent- 
schieden werden. ob der Ladevorgang wiederholt wird 
Oder ob die alte Anwendersoftware wieder in den passi- 
ven Rechner geladen wird Transiente Softwarefehler 
konnen repariert werdea indem die Anwendersoftware 
des einen Rechners automatisch durch diejenige des an- 
deren Rechners geladen wird. 

Es folgt nun die Beschreibung der Erfindung anhand 
der Figuren. 

Die Fig. 1 zeigt ein grobes Blockschaltbild des Dop- 
pelrechnersystems. 

In Fig. 2 sind die aktiven Programme und ihre Kom- 
munikationspfade schematisch dargestellt. 

Fig. 3 schlieBlich zeigt in Form eines FluBdiagramms 
den logischen Ablauf des erfindungsgemaBen Verfah- 
rens. 

Die Fig. 4 zeigt ein deiaillierteres Blockschaltbild fur 
ein Ausfuhrungsbeispiei eines Doppelrechnersystems. 

Die schemaiische Darstellung der Fig. I zeigt ein 
Doppelrechnersystem mit zwei identischen Rechnern 1 
und Z die uber einen internen Datenkanal RRDK mii- 
einander verbunden sind Zusitzlich sind beide Rechner 
uber je einen externen Datenkanal EDK mit einer uber- 
geordneten Kontroilinstanz bzw. externen Datenquelle 
verbunden bzw. verbindbar; d h. nur einer der beiden 
externen Datenkanale ist fur die Datenubenragung mit 
oder von der Kontroilinstanz offen. und zwar ist dies 
derjenige externe Datenkanal weicher zu dem Rechner 
fuhn, der im Augenblick fur alle durchzufuhrenden Auf- 
gaben zustandig ist. Dieser Rechner wird als akiiver 
Rechner bezeichnei, wahrend der andere Rechner, wei- 
cher momentan keine Aufgaben bearbeiteu als Stand- 
by- Rechner bezeichnet wird Die Entscheidung daruber. 
weicher der Rechner aktiv bzw. standby geschaltet 1st, 
wird von einer ubergeordneten Kontroilinstanz, von ei- 
nem Diagnoserechner oder einer ahnlichen Oberwa- 
chungseinheit getroffen. Die Umschaltung erfolgt durch 
entsprechende Kommandos, welche an beide Rechner 
gesendet werden. Bei einer Umschaltung verandert sich 
auch der Zustand der externen Datenkanale EDK. 

In Fig. 2 ist eine schematische Darstellung der auf den 
Rechnern aktiven Programme und ihre Kommunika- 
tionspfade gezeichnet Beide Rechner sind mit einem 
Multitaskingbetriebssystem ausgestattet. Programme, 
die auf den Rechnern ausgefuhrt werden, werden als 
Prozesse gezeichnet. Jedem ProzeB wird eine individu- 
elle Ablaufprioritat zugeordnet. wodurch bestimmte 
Prozesse gegenuber anderen bevorzugt bearbeitet wer- 
dea Diejenigen Prozesse, welche fur das Laden emer 
neuen Softwareversion zustandig sind werden umer 
dem Begriff Download-Software DLSW zusammenge- 
faBt Sie wird mit einer Ablaufprioritat ausgestattet, die 
garaniiert, dafl andere Prozesse, welche betnebliche 
Aufgaben bearbeiten, also die sogenannten Applikatio- 
nen Appl, bevorzugt werden. Dadurch wird garantiert, 
daB der laufende Betrieb der Applikationen, namlich 
Fuhrung und Steuerung der Peripherie, nicht durch das 
Laden einer neuen Softwareversion beeintrachtigt oder 
gar unierbrochen wird Ober den externen Datenkanal 
EDK konnen von einer ubergeordneten KoniroUm- 
stanz Kommandos an den aktiven Rechner gesendet 
werden. Mitteis eines Parsers wird entschieden bzw. 
festgestellt ob diese Kommandos fiir die Applikationen 
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AppI Oder fur die Download-Software DLSW bestimmt 
sind. Der EntscheidungsprozeQ erfolgt dabei so, daB die 
Adressc der empfangenen Kommandos ausgewertet 
und die Kommandos entsprechend an den jeweihgen 
Adressaten weiiergeleitei werden. Die Download- Soft- 5 
ware DLSW auf dem aktiven Rechner RA hat die Auf- 
gabe, die von der IControlUnstanz empfangenen Kom- 
mandos Qber den intemen Rechnerrechnerdatenkanal 
RRDK an die Download-Software DLSW des Standby- 
Rechners weiterzusenden und durch kontinuierliches 10 
Austauschen von Kommandos mit der Kontroilinstanz 
die Funktionstuchtigkeit des aktiven Rechners und sei- 
ner Software anzuzeigen. Die Download-Software 
DLSW des Standby- Rechners hat die Aufgabe, seine 
Programme auf das Laden einer neuen Softwareversion 15 
vorzubereiten, diese zu laden und zu starten. Sowohl fur 
das Veranlassen der Vorbereitung auf das Laden emer 
neuen Softwareversion als auch zur Durchfuhrung des- 
selben werden Kommandos von der KontroUinsianz 
uber die Download-Software DLSW des aktiven Rech- 20 
ners an die Download-Software DLSW des Standby- 
Rechners ubertragen. 

Die Fig. 3 zeigt in Form eines Flulkliagramms den 
logischen Ablauf des erfindungsgemaOen Verfahrens 
zum Einspielen einer neuen Softwareversion auf em 25 
Doppeirechnersystem. Im Ausgangszustand 1 befinden 
sich beide Rechner in einem Betriebszustand. in dem mit 
der alten Softwareversion gearbeitet wird. Als erster 
Schritt des Ladevorgangs wird ein Kommando von der 
Kontroilinstanz oder ubergeordneien Insianz Qber den 30 
offenen externen Datenkanai EDK an die Download- 
Software DLSW des aktiven Rechners gesendet: letzte- 
re leitei das Kommando uber den internen Datenkanai 
RRDK an die Down-Load-Sofiware DLSW des Stand- 
by- Rechners weiter. Die Prozesse auf dem Standby- 35 
Rechner werden daraufhin auf das bevorsiehende La- 
den einer neuen Anwendersoftwareversion vorbereitet, 
2. Das Laden 3 der neuen Softwareversion erfolgt von 
einer externen Datenquelle, die sich auch bei der uber- 
geordneien Kontroilinstanz befinden kann, uber den ak- 40 
tiven Rechner auf den Standby- Rechner. Dazu werden 
die zu ubertragenden Daten in Form von KontroUkom- 
mandos, welche die Daten enthalten, an die Download- 
Software DLSW auf den aktiven Rechner gesendet 1st 
die neue Softwareversion auf dem Standby- Rechner 45 
vollstandig geladen, so gibt es zwei Moglichkeiten. Er- 
stens von der Kontroilinstanz wird ein Umschalten 4 
(gemaO Fig. 3) der Rechnerzustande vorgenommen. 
Der zuvor akiive Rechner mit der alien Softwarever- 
sion geht in den Zusiand standby uber, und der im Zu- 50 
stand standby befindliche Rechner mit der neuen Soft- 
wareversion geht entsprechend in den Zustand aktiv 
uber. Stellt sich nun heraus, daB die neue Softwarever- 
sion fehlerhaft 9 ist, so wird ein sofortiges Ruckschalten 
der Rechnerzustande 10 bewirkL Die RQckschaltung 55 
muB naturlich so schnell erfolgen, daB eine Beeintrachti- 
gung der Betriebsablaufe nicht erfolgt. 

Die zweite Moglichkeit (nicht gezeichnet in Rg. 3) 
sieht vor, daB vor einer Umschahung der Rechnerzu- 
stande die neue Softwareversion auf dem Standby- eo 
Rechner gestanei und beispielsweise mittels einer Dia- 
gnose Oder Oberwachung auf Fehier untersucht wird. 
Bei Fehlerfreiheit kann dann eine Umschaltung so erfol- 
gen, daB die Bearbeitung von Aufgaben auf dem aktiven 
Rechner kontroiliert eingestcHt wird Wcnn alie in Bear- 65 
beitung befindlichen Aufgaben der Applikationen erle- 
digt sind, wird die Verbindung zu der Kontroilinstanz 
uber den externen Datenkanai EDK abgebaut und urn- 
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geschaltet. Der nach der Umschaltung akiive Rechner 
baut die Verbindung zur Kontroilinstanz wieder auf und 
signalisiert damit. daB die neue Softwareversion korrekt 
gcstartet wurde» 5. Nunmehr wird der jetzige Standby- 
rechnen beispielsweise durch ein Kommando der Kon- 
troilinstanz, auf das bevorsiehende Laden der neuen 
Softwareversion vorbereitet, 6. Das Laden derselben 
erfolgt, indem sie direkt vom aktiven Rechner uber den 
internen Datenkanai RRDK in den Standby- Rechner 
ubertragen wird, 7. Diese Verfahrensweise enilastei ge- 
nerell den externen Datenkanai EDK und isi naturlich 
von Vorteil. wenn die Obenragungskapazitat des exter- 
nen Datenkanals gegeniiber derjenigen des intemen 
Daienkanals unterlegen ist Nach Beeendigung des La- 
devorganges sind beide Rechner mit einer neuen Soft- 
wareversion ausgestaiiet und befinden sich im Betrieb8. 

Ober den Fall, daB die neue Softwareversion per se 
fehlerhaft ist, wobei z. B. der Ladevorgang korrekt und 
fehlerfrei erfolgt ist, so kann beispielsweise durch die 
ubergeordnete Kontroilinstanz entschieden werden, 
daB der Standby-Rechner wieder mit der alten Softwa- 
reversion geladen wird. Er wird darauf vorbereitet, 1 1, 
worauf im Vorgang 12 diese uber den internen Daten- 
kanai RRDK vom aktiven auf den Standby-Rechner 
ubertragen wird. Erfolgt dies fehlerfrei. so befinden sich 
beide Rechner wieder im Betriebszustand 13 mil der 
alten Softwareversion. 

Beim Laden einer neuen Softwareversion konnen 
grundsatzlich zwei Vorgehensweisen unierschieden 
werden. Die eine geht davon aus. daB die neue Softwar 
reversion kompiett von der externen Daienqueile bzw. 
Kontroilinstanz auf den Standby-Rechner ubertragen 
wird. Dies ist dann noiwendig. wenn es sich um eine 
neue Softwareversion handelt, die keine alten Telle oder 
Moduln wiederverwenden kann. 

Die zweite Vorgehensweise geht davon aus, dafi bei 
einer neuen Softwareversion lediglich ein kleiner Teil 
geandert wurde. der Rest jedoch unverandert bleibt. In 
diesem Fall ist es moglich, lediglich den gegenuber der 
alten Version geanderten Teil bzw. das geanderte Mo- 
dui der neuen Softwareversion von der Kontroilinstanz 
bzw. externen Datcnquelle auf den Standby-Rechner zu, 
Qbertragen. Die restlichen unveranderten Telle der al- 
ten Softwareversion werden dann vom aktiven Rechner 
uber den internen Datenkanai auf den Standby-Rechner 
ubertragen. Bei einer soichen Verfahrensweise wird der 
externe Datenkanai EDK durch den Ladevorgang weni- 
ger belasiet. 

Die bisherige Beirachtungsweise ging davon aus, dafl 
der mit neuer Anwenderscftware zu ladende Standby- 
Rechner in einen Zustand zuriickgeseizt wird, indem 
nur noch das Betriebssystem bzw. die fur den Ladevor- 
gang notwendigen Programmmoduin nicht geloscht 
sind. Es sind naturlich auch Verfahrensweisen denkbar, 
bei denen eine totale Zuriickseizung nicht erfolgt, son- 
dern bei denen lediglich Teile oder Moduln der alten 
Anwendcrsoftwarc crsctzt werden durch cine neue ge- 
anderte Version. Beim Ladevorgang muB dann naturlich 
eventuell die unterschiedliche Lange der Softwareteile 
der alten und neuen Version berucksichtigt werdea was 
zu einer Verschiebung im Speicher oder veneilten Ein- 
speicherung fuhren kann. Eine soiche Vorgehensweise 
entlastet den Verkehr sowohl auf dem externen als auch 
auf dem internen Datenkanai. 

Die Rg. 4 zeigt ein detaillierteres Blockschaltbild fur 
ein Ausfuhrungsbeispiel einer Doppelrechneranord- 
nung. Das Doppeirechnersystem besteht aus dem linken 
aktiven Rechner Ra und dem rechten passiven Rechner 
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Rs. Beide Rechner sind wiederum Doppelrechnersyste- 
me in der Architekiur eines Hauptrechners oder zentra- 
len Rechners ZR, dem ein Input-Outputrechner lOR 
eigens fQr Ein-ZAusgabe-Aufgaben yorgeschaltei ist 
Beide Hauptrechner sind uber einen Uberwachungska- 5 
nal Ok mit einer Oberwachungseinheit oder hier einem 
Diagnoserechner DR verbunden. Uber diesen Oberwa- 
chungskanal werden Report- bzw. Quittungssignale 
ausgeiauscht Die Oberwachung schlieBt natiirlich je- 
weils den Ein-Ausgaberechner lOR mit ein. Die Kon- 10 
trollinstanz ist hier der Diagnoserechner DR, durch den 
auch die Umschaltung der Rechner in den akiiven bzw. 
passiven Zustand erfolgt, angedeutet durch die gestri- 
chelten Linien, welche sowohl zum zentralen Rechner 
ZR als auch zum vorgeschalten Ein-Ausgaberechner 15 
lOR fuhren. 

Die Daienkanaie EDKa und EDfCs fuhren auch je- 
weils uber den Ein-/Ausgaberechner lOR- In der darge- 
siellien Realisierung verbindet der Diagnoserechner. 
DR den Datenkanal EDKa des augenblicklich akiiven 20 
Zenirairechner (ZRa) mit dem externen Datenkanal 
EDK. Auf diese Weise muQ die ubergeordnete Kontroll- 
instanz lediglich eine Schnittstelle bedienen und das ge- 
samte in Fig. 4 dargestelhe Rechnersystem stellt sich 
der ubergeordneten Kontrollinsianz wie ein Einprozes- 25 
sorsystem dar. 

Patentanspriiche 

1. Verfahren zum Laden eines Doppelrechner- 30 
Standby Systems mit neuer Anwendersoftware, 
wobei die beiden Rechner uber einen internen Da- 
tenkanal miteinander verbunden und jeweils uber 
einen externen Datenkanal mit einer externen Da- 
tenqueile verbindbar sind und jeweils uber ein Mui- 35 
titaskingbetriebssystem verfiigen, mit einer Uber- 
wachungs- oder Diagnoseeinheit. durch welche die 
beiden Rechner wechselseitig in einen aktiven bzw. 
einen passiven Zustand schaltbar sind gekeim- 
zeichnet durch die folgenden Schritte: 40 

a) der passive Rechner wird auf das Laden 
vorbcreiiet, 

b) die neue Anwendersoftware wird von der 
externen Datenquelle uber den externen Da- 
tenkanal in den Speicher des aktiven Rechners 45 
iibertragen, 

c) die neue Anwendersoftware wird vom akti- 
ven Rechner uber den internen Datenkanal in 
den Speicher des passiven Rechners iibertra- 
gen, 50 

d) nach Beendigung dieser Obertragung wird 
die in Schritt c) geladene Anwendersoftware 
des passiven Rechners gestartet, 

el ) lauft die neue Anwendersoftware fehlerlos, 
so wird der bis dahin passive Rechner in den 55 
aktiven Zustand umgeschaltet und der bis da- 
hin akiive Rechner in den passiven Zustand 
umgeschaltet. und es folgt Schritt f), 
e2) im Fehlerfall unterbleibt die Umschaltung, 
und es folgt Schritt h), eo 
f) es folgen die Schritte a)» c) und d\ 
gl) lauft die neue Anwendersoftware fehler- 
frei, ist der Ladevorgang beendet, 
g2) im Fehlerfall werden die Schritte 0 und g) 
wiederholt; 65 
h) durch eine ubergeordnete Kon trollinstanz 
wird entschieden, ob die Schritte a) und e) wie- 
derholt werden oder ob die aite Anwender- 



207 CI 

6 

software vom aktiven Rechner wieder in den 
passiven Rechner geladen wird. 

2. Verfahren nach Anspruch K dadurch gekenn- 
zeichnet. daB die Vorbereitung auf das Laden des 
passiven Rechners durch das Ladeprogramm des 
aktiven Rechners erfolgt indem eine Kommunika- 
tion zwischen ihren beiden Ladeprogrammen auf- 
gebaut wird. 

3. Verfahren nach Anspruch 2, dadurch gekenn- 
zeichnet, daB das Ladeprogramm des aktiven 
Rechners per Befehl uber den externen Datenkanal 
zur Vorbereitung auf das Laden des passiven Rech- 
ners (Schritt a)) veranlaBt wird. 

4. Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet. dafi die Obertra- 
gung der neuen Anwendersoftware gemaB Schritt 
b) durch blockweise Zwischenspeicherung der zu 
Qbertragenden Anwendersoftware im Arbeitsspei- 
Cher des aktiven Rechners erfolgt, daB anschiie- 
Bend der zwischengespeicherte Block gemaB 
Schritt c) in den passiven Rechner geladen wird und 
daB die Schritte b) und c) gemaB der Anzahl der zu 
iibenragenden Blocke wiederholt werden. 

5. Verfahren nach einem der vorhergehenden An- 
spruche, dadurch gekennzeichnet. daB das Laden 
wahrend des laufenden Betriebes erfolgt. 

6. Verfahren nach Anspruch 5, dadurch gekenn- 
zeichnet daB das Laden mit einer niedrigen Priori- 
tat bearbeitet wird. 

7. Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet, daB der Lade- 
vorgang in den passiven Rechner gemaB Verfah- 
rensschritt c) durch das Ladeprogramm des aktiven 
Rechners erfolgt, indem eine Kommunikation zwi- 
schen ihren beiden Ladeprogrammen aufgebaut 
wird. 

8. Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet, daB die uberge- 
ordnete Kontrollinstanz die Oberwachungs- oder 
Diagnoseeinheit ist 

9. Verfahren nach einem der vorhergehenden An- 
spruche 1 bis 7. dadurch gekennzeichnet dafi die 
ubergeordnete Kontrollinstanz die exteme Daten- 
quelle ist 

. 10. Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet daB, wenn die 
neue Anwendersoftware lediglich einen Teil oder 
einen Modui der gesamten Anwendersoftware be- 
trifft Oder umfaBt nur dieser Teil bzw. Modui iiber 
den externen Datenkanal zum aktiven Rechner 
ubertragen wird. 

1 1. Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet daB der passive 
Rechner mitteis des Ladeprogramms des akiiven 
Rechners mit neuen und/oder alten Anwendersoft- 
waremodulen ladbar ist 

IZ Verfahren nach einem der vorhergehenden An- 
spriiche, dadurch gekennzeichnet daB der passive 
Rechner zur Vorbereitung auf das Laden mit Aus- 
nahme seines Bciriebssystems in einen geloschten 
Zustand zuriickgesetzt wird. 
13. Verfahren nach einem der vorhergehenden An- 
spruche, dadurch gekennzeichnet daB am An- 
schluB des externen Datenkanals vor dem Rechner 
ein Input-Output-Rcchncr (lOR) eingefugt ist 
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1 Siemens Aktiengesellschaf t 

Steuerungssystem eines Vermltt lungs systems 

5 Die Leistungsfahigkeit und Wei terentwicklungsfahigkei t 
bzw. Veranderbarkeit eines Vermittlungssystems sind in 
starkem MaSe von der Flexibilitat des Steuerungssystems 
abhangig . 

10 Der Erfindung liegt die Aufgabe 2u Grunde, ein flexibles 
Steuerungssystem eines Vermittlungssystems anzugeben* 

Diese Aufgabe wird durch die Merkmale des Anspruchs 1 
gelost . 

15 

Mit Hilfe des er f indungsgemaSen Diens temanagementsystems 
konnen die Dienstleistungsmodule einen Dienst bzw. genauer 
gesagt einen Kommunikationspfad zu einem Dienst nunmehr in 
einfacher Weise durch Angabe des Namens des Dienstes an- 
^ 20 fordern, ohne seinen Ort innerhalb des Steuerungssystems 
zu kennen. Eine Kommunikationsbeziehung zwischen einem 
aufrufenden Dienst und einem aufgerufenen Dienst wird 
somit dynamisch aufgebaut. Damit ist die Grundlage fur 
eine unproblematische Veranderbarkeit der Konf iguration 
25 des Steuerungssystems wahrend des Betriebs geschaffen. 

Eine Ausgestaltung der Erfindung ist durch Anspruch 2 
angegeben. Durch diese Ausgestaltung ist es moglich, das 
Steuerungssystem dynamisch aufzurusten oder zu erweitern* 
30 Des weiteren konnen bei dieser Ausgestaltung alte Dienst- 
leistungsmodule dynamisch aus dem System entfernt werden, 
indem die Schritte zur Installation neuer Dienstleistungs- 
module in umgekehrter Richtung angewandt werden. 

35 Eine weitere Ausgestaltung der Erfindung ist durch Anspruch 
3 angegeben. Durch diese Ausgestaltung ist es moglich, die 
ortliche Verteilung der installierten Dlenstleistungsmodu- 
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le dynamisch zu verandern, indem die Oienstleitungsmodule 
auf die neuen Orte vervielf Ml tigt werden, wahrend die 
Dienstleistungsmodule auf dem ursprungllchen Ort auGer 
5 Betrieb genommen werden. 

Eine weitere Ausgestaltung der Erfindung ist durch An- 
spruch 4 angegeben. Bei dieser Ausgestaltung wird zum 
einen eine gleichmaSigere Verteilung der Last zwischen den 
10 verarbeitungsplattformen des Steuerungssystems erreicht 

und zum anderen eine groBere unabhangigkeit bezuglich des 
Ausfalls bzw. AuQerbetriebnehmen eines Dienstleistungsmo- 
duls erreicht. 

15 Eine weitere Ausfuhrungsf orm der Erfindung ist durch 

Anspruch 5 angegeben. Durch diese Ausfuhrungsf orm wird 
eine asynchrone Kommunikation zwischen dem aufrufenden 
Dienstleistungsmodul und dem aufgerufenen Dienstleistungs- 
raodul ermoglicht. 

20 

Eine weitere Ausfuhrungs f orm der Erfindung ist durch 
Anspruch 6 angegeben. Durch diese Ausfuhrungsform wird 
eine synchrone Kommunikation zwischen dem aufrufenden 
Dienstleistungsmodul und dem aufgerufenen Oienstleistungs- 
25 modul ermoglicht. 

Eine weitere Ausgestaltung der Erfindung ist durch An- 
spruch 7 angegeben. Durch die fur eine Dienstleistungs- 
kapsel mogliche individuelle Zuteilung von Betriebsmitteln 
30 kann erreicht werden, daB die Betriebsmittel fur solche 

Funktionen, die fur die Integritat und den Betrieb des Sy- 
stems notwendig sind, in ausreichendem MaBe gegenuber sol- 
chen Funktionen reserviert werden, die weniger dringend 
sind und viele Betriebsmittel benotigen (z.B. verkehrsmessung) 

35 
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Im folgenden wird die Erfindung anhand der Zelchnung 
naher eriautert. 

FIG 1 zeigt ein Schalenmodell fur Verarbeitungsplatt for- 
^ men mit System- und Anwendungs-Sof tware , 

FIG 2 zeigt die Anforderung eines bestimmten Dienstes 
durch einen entsprechenden Aufruf an das Dienstemanagement- 
systera des Betriebssystems , 

FIG 3 zeigt die Kommunikation zwischen zwei Dienstinstanzen 
mit Hilfe von Meldungen, 

FIG 4 zeigt die Kommunikation zwischen zwei Dienstinstan- 
zen mit Hilfe von Remote-Prozedur-Auf ruf en, 
FIG 5 zeigt die Dienstetabelle sowie den Ablauf zur Ver- 
anderung der Dienstetabelle. 

15 

FIG 1 zeigt ein Schalenmodell fur Verarbeitungsplattf ormen 
eines Steuerungssystems , das folgende Schalen aufweist: 
Eine erste Schale, die der Hardware der betrachteten drei 
Verarbeitungsplattf ormen entspricht , 

einer zweiten Schale, die der Firmware (Urlader, Hardware- 
Schnittstelle, Fehlererkennung , usw.) der Verarbeitungs- 
plattformen entspricht, 

eine dritte Schale, die der Betriebssystera-Sof tware (Be- 
triebssystemkern, Fehlerbehandlung) entspricht, 
eine vierte Schale, die der Basis-Software (Oatenbasis, 
Uberlaststeuerung usw.) der Verarbeitungsplattform ent- 
spricht und die mehrere Dienstleistungskapseln DLK umfaSt, 
eine funfte Schale, die der System-Software (Konfigura- 
tlons-Software, Recovery-Software usw.) der Verarbeitungs- 
plattform entspricht und die ebenfalls mehrere Dienstlei- 
stungskapseln DLK umfaSt, 

eine sechste Schale, die der Anwender-Sof tware (Vermitt- 
lungstechnik, ATM-Cross-Connect, Protokollabwicklung usw.) 
der Verarbeitungsplattform entspricht, und die ebenfalls 
mehrere Dienstleistungskapseln DLK umfaQt. 



20 



30 
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Nur die oberhalb der zweiten Schale ablaufende Software 
wird in Dienstleistungsmoduln SPU zusammengef aQt und in 
Dienstleistungskapseln DLK gekapseit. Die Schalen 1 bis 
5 3 stellen zusammen die Grundverarbeitungsplatt form dar 
und sind fur jeden Verarbeitungsplatt f ormtyp gleich. 

Mit dem Oienstleistungsmodul steht dem Entwickler ein gro- 
Gerer und zweckmaSigerer Container als der heutige Prozess 

10 zur Verfugung, Ein Oienstleistungsmodul ist eine Menge von 
Modulen und Prozessen, die eine starke funktionale Bezie- 
hung zueinander haben und zusammen eine Gruppe von Dien- 
sten fur die ubrige Software Oder den Teilnehmer des Ver- 
mittlungssystems zur Verfugung stellen. Seine Komponenten 

15 (Module und Prozesse) befinden sich garantiert im selben 
Adressraum des Speichers. Deshalb konnen fur die Kommuni- 
kation innerhalb eines Dienstleistungsmoduls lokale Proze- 
duraufrufe und gemeinsame Speichermechanismen benutzt 
werden. 

20 

Das Oienstleistungsmodul ist eine relozierbare Einheit, 
d.h. es kann von einer Dienstleistungskapsel zu einer 
anderen Dienstleistungskapsel und ebenso von einer Verar- 
beitungsplattform zu einer anderen Verarbeitungsplattf orm 

25 zur Produktionszeit des Steuerungssystems bewegt werden. 
Daraus ergibt sich, daQ die Schnittstellen eines Dienst- 
leistungsmoduls durch Ausdrucke der Inter^ProzeQ-Kommuni- 
kation definiert werden mussen (z.8* CAST, Remote-Proze- 
duren). Jede Aktion Oder jeder Steuerungsdatenf luQ zwi- 

30 schen zwei Dienstleistungsmodulen wird durch die Ubergabe 
von Meldungen ausgelost. Die Kommunikation zwischen zwei 
Dienstleistungsmodulen erfolgt somit ausschlieBlich uber 
das Betriebssystem. Daruber hinaus ist das Design und die 
Implementation eines Dienstleistungsmoduls "location 

35 transparent", d.h. ein Oienstleistungsmodul braucht keine 
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Kenntnis davon 2u haben auf welcher verarbeitungsplattf orm 
es ablauft und auf welchen Verarbeitungsplatt f ormen 
eventuelle Kommunikationspartner laufen. 

Ein Dienstleistungsmodul kann weiterhin vervielfaltigt 
werden, so daQ dasselbe Dienstleistungsmodul sowohl auf 
mehreren Steuerungsprozessoren als auch mehrmals auf einem 
einzigen steuerungsprozessor auftreten kann. Die Verviel- 
faltigung kann sowohl zum Produktionszei tpunkt des Systems 
stattfinden oder sogar wahrend der Laufzeit des Systems. 
Durch die genannte Vervielf al tigbarkeit eines Dienstlei- 
stungsmoduls wird die Flexibilitat des Systems bezuglich 
der Lastverteilung und der Erweiterbarkeit unterstutzt. 

Das Dienstleistungsmodul spielt innerhalb des Systems zwei 
unterschiedliche Rollen. Es kann zum einen Dienstleistun- 
gen fur andere Dienstleistungsmodule ausfuhren, oder zum 
anderen Dienstleistungen von anderen Dienstleistungsmodu- 
len anfordern. In dem erstgenannten Fall handelt es als . 
Server, wahrend es im zwei tgenannten Fall als Client han- 
delt. Einige Dienstleistungsmodule konnen ausschlieQlich 
als Server handeln, wahrend andere wiederuro als aus- 
schlieQliche Clienten handeln. Im allgemeinen jedoch 
spielt ein Dienstleistungsmodul beide Rollen. 

Damit ein Dienstleistungsmodul die Dienstleistungen eines 
anderen Dienstleistungsmodul in Anspruch nehmen kann, muB 
es wissen, welche Dienstleistungen von dem Server-Dienst- 
leistungsmodul zur Verfugung gestellt werden. Zu diesem 
Zweck stellt jedes Dienstleistungsmodul sogenannte 
Dienstschnittstellen zur Verfugung, in der die Dienste 
beschrieben sind, die das Dienstleistungsmodul innerhalb 
des Systems zur Verfugung stellt. Diese Dienstschnitt- 
stellen werden, nachdem ein Dienstleistungsmodul in 
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das System geladen worden ist, gegenuber dem Betriebs- 
system bekannt gemacht. so daQ andere Dienstleistungsmo- 
dule die Dienstleistungen des geladenen Dienstlelstungs- 
moduls uber das Betriebssysstem ab diesem Zeitpunkt in 
Anspruch nehmen konnen. 

Eine Dienstschnittstelle beinhaltet den Namen und Typ des 
Dienstes, eine Gruppe von Remote-Prozeduren und Remote- 
Puffern, sowie weitere den zugehorigen Dienst spezifi- 
zierende Datenobjekte, z.B. Partition. 

Das Dienstleistungsmodul stellt einen eigenstandigen Bau- 
stein zur Systemerstellung dar. der uber seine Olenst- 
schnittstellen von anderen Dienstleistungsmodulen aufge- 
rufen werden kann. Nach der Installierung dieses Baustelns 
innerhalb des Systems kann man ihn auf verschiedene Art 
mit anderen Dienstleistungsmodulen zusammenf assen , urn neue 
Systemleistungen bereitzustellen. Dieses Prinzip ist auch 
die Basis fur Standardbausteine zur Software-Erstellung, 
die der momentanen Standardisierung intelligenter Netze 
entsprechen- 

im folgenden wird ein weiterer Software-Container, 
namlich eine Dienstleistungskapsel DLK naher erlautert. 

Die Dienstleistungskapsel umfaSt eine Gruppe von Dienst- 
leistungsmoduln. denen gemeinsam ein bestimmtes Budget von 
Betriebsmitteln (z.B. geschutzter Adressraum, zwei Spei- 
cher Zeitgeber) zur Verfugung gestellt ist. Eine Dienst- 
leistungskapsel kann on-line. d.h. ohne Betriebsunterbre- 
chung, in das System eingebracht oder durch eine aufgeru- 
stete Version ersetzt werden. 

Durch das Zusammenf assen von Dienstleistungsmodulen in 
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Dienstleistungskapseln lassen sich neue Systems Oder 
kundenspezif ische Leis tungsmerkmale schaffen* Daruber hin- 
aus ist es moglich, bestehenden Dienstleistungskapseln 
5 geanderte oder vollstandig neue Dienstleistungsmodule hin- 
zuzufugen. Die Tatsache, daQ Dienstschnitts tellen gewartet 
werden konnen, ermoglicht das Erstellen neuer Kombina- 
tionen zu niedrigen Kosten und in kurzerer Zeit. Daruber 
hlnaus konnen die Prufung und Wartung eines Dienstlel- 
10 stungsmoduls als isolierbare Funktionseinhei ten ausge- 

fuhrt werden. Dadurch werden ubergreif ende Funktionstests 
in Umfang und Komplexitat vermindert, was die Entwick- 
lungskosten weiter reduziert. 

15 Das Aufrusten von Betriebsvermittlungsstellen durch Hin- 
zufCigen von Dienstleistungskapseln ist ein Mittel, Ent- 
wicklungskosten zu vermindern und dadurch Wettbewerbsvor- 
teile zu erhalten, Auf diese Weise kann der Netzbetreiber 
neue Leistungsmerkmale mit verringerter Logistik schnell 

20 in das Netz einbringen* Die neuen Merkmale lassen sich 
in bestehenden oder neuen Verarbeitungsplatt formen 
hinzufugen. In beiden Fallen sind folgende Schritte 
er f orderlich : 

25 In einem ersten Schritt werden die Dienstleistungskapsel 
off-line durch Zusammenf assen mehrerer Dienstleistungs- 
module erstellt und anschlieSend an die entsprechenden 
Vermittlungss tellen ausgelief ert • 

In einem zweiten Schritt werden in einer entsprechenden 
30 Vermittlungsstelle on-line neue Verarbeitungsplatt form- 
typen erstellt. 

In einem dritten Schritt vollzieht sich das Laden neuer 
Kapseln in bestehende Verarbeitungsplatt formen, urn neue 
Verarbeitungsplattformtypen zu vervollstandigen , oder das 
35 Laden volls tandiger Verarbeitungsplattformtypen in neue 
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Verarbeltungsplatt formen. 

In einem vierten Schritt vollzieht sich schlieQlich das 
Aktivleren neuer Kapseln Oder eines neuen 
5 Verarbeitungsplaltt f ormtyps auf der bestehenden bzw. neuen 
Verarbeltungsplatt form . 

Durch die genannten Schrltte kann elne neue Kombinatlon 
bestehender Funktionen ohne Betriebsstorung in das System 
10 eingefCjgt werden. Neue Lelstungsmerkmal-Sof tware laOt slch 
auf dieselbe Weise einbringen, well das Betriebssystem je- 
de Dienstleistungskapsel als eigene Verarbeitungseinhei t 
behandelt. 

15 Wle bereits vorher erwahnt, werden Kommunikationsbezie- 
hungen zwischen den Dienst leistungsmoduln dynamisch her- 
gestellt. Diese Funktion wird im folgenden als Dienste- 
adressierung bezelchnet und durch ein Dienstemanagement- 
system Innerhalb der Betriebssystem-Sof tware zur Verfu- 

20 gung gestellt. 

Jede Implementierung eines bestimmten Dienstes innerhalb 
eines Dienstleistungsmoduls wird als Instanz eines be- 
stimmten Dienstes (Diensttyp) oder abgekurzt einfach als 

25 Dienstinstanz bezeichnet. Die von einem Dienstleistungsmo- 
dul durch entsprechende Dienst instanzen zur Verfugung ge- 
stellten Dienstleistungen werden dem System in bereits 
erwahnten Dienstschnittstellen bekanntgegeben. Dabei liegt 
fur jede Dienstinstanz eine entsprechende Dienstschnitt- 

30 stelle vor, die von dem jeweiligen Dienstleistungsmodul 
exportiert und in einer Spezif ikation (Kurzerklarung mit 
Syntax und Semantik) erlautert wird* 

Immer wenn eine Dienstinstanz eines Dienstleistungsmoduls 
35 eine Kommunikationsbeziehung mit einer anderen Dienstin- 
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stanz eines anderen Diens tleistungsmoduls zwecks Ausfuh- 
rung elnes Dlenstes herstellen will, so fuhrt sie uber das 
Betrlebssystem einen Aufruf an das Dienstemanagementsystem 
5 durch, in welchem der Name des Typs des angeforderten 

Dienstes und gegebenenf alls zusatzliche Kriterien fur die 
Auswahl eines Server-Dienstleistungsmoduls angegeben 
werden. 

10 Mogliche zusatzliche Auswahlkriterien sind 

- eigene Verarbeitungsplatt form, d.h, geringster dynami- 
scher Aufwand, 

- Partitionen, die den Dienst auf einen bestimmten Daten- 
Bereich Oder Ressourcen-Bereich eingrenzen, 

15 - explizite Angabe der Verarbeitungsplattf orm und/oder der 
Dienstleistungskapsel • 

.•-1 /• 
Als Resultat des Aufrufs erhalt die auf ruf ende ^Kunden- ^ 
Dienstinstanz einen sogenannten Kommunikationspf ad zu- 

20 ruck, mit Hilfe dessen die Kommunikation zu der ausge- 

wahlten Server-Diens tinstanz aufgenommen werden kann. Bei 
dem Kommunikationspf ad handelt es sich urn ein Datenfeld, 
das im wesentlichen Remote-Ref erenzen (RPC's und CAST) zu 
der ausgewahlten Server-Dienstinstanz enthalt. Die eigent- 

25 liche Kommunikation wird sodann durch Senden von Meldungen 
(Cast) Oder Aufrufen von Remote-Prozeduren (RPC) durchge- 
fuhrt. 

FIG 2 zeigt die Anforderung eines bestimmten Dienstes 
30 durch den Aufruf "Connect-Service" an das Dienste-Manage- 
ment System eines Betrlebssystem BS. In Fig. 2 erfolgt 
der genannte Aufruf innerhalb einer Verarbeitungsplatt- 
form GP3 eines Steurungssy stems , das noch zwei weitere 
Verarbeitungsplattformen GPl und GP2 aufweist. Als Resul- 
35 tat des genannten Aufrufs erhalt die aufrufende Dienst- 
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instanz des Diens tleistungsmoduls SPUO eine Referenz auf 
die Dienstschnittstelle einer Diens tinstanz , die den an- 
geforderten Dienst ausfuhren kann. Die genannte Dienst- 
schnittstelle enthalt u. a. eine Sammlung von Remote-Ref e- 
renzen, mit deren Hilfe in Form von Meldungen (Cast) und 
Remote-Prozedur-Aufrufen (RFC) die Kommunikat ion mit der 
vom Dienstemanagement ausgewahlten Diens tinstanz 
durchgefuhrt werden kann. 



Bei der Auswahl einer geeigneten Dienstinstanz beruck- 
sichtigt das Diens temanagement system Last-/und Mainte- 
nance-Zustande derjenigen Plattformen, auf denen sich 
geeignete Dienstinstanzen befinden. Die Inf ormationen uber 
15 die genannten Piatt formzustande entnimmt das Diens tmanage- 
mentsystem einer eigenen lokalen Zustandstabelle, die durch 
das Uberlastbehandlungssystem und das Maintenance-System 
regelmaQig aufdatiert wird. 

20 FIG 3 zeigt die Kommunikat ion zwischen zwei Dienstinstan- 
zen mit Hilfe von Meldungen. Bei dem Steuerungssystem auf 
der linken Seite von FIG 3 befindet sich die anfordernde 
Dienstinstanz in dem Dienstleistungsmodul SPUO des Steue- 
rungsprozessors GP3 und die ausgewahlte Dienstinstanz 

25 innerhalb des Dienstleistungsmoduls SPUl desselben Steue- 
rungsprozessors. Bei dem Steuerungssystem auf der rechten 
Seite von FIG 3 befindet sich die anfordernde Dienst- 
instanz in dem Dienstleistungsmodul SPUO des Steuerungs- 
prozessors GP3 und die ausgewahlte Dienstinstanz in dem 

30 Dienstleistungsmodul SPUl des Steuerungsprozessors GPl. 

FIG A zeigt die Kommunikation zwischen zwei Dienstinstan- 
zen mit Hilfe von Remote-Prozedur-Aufrufen (RPC). Die 
ortllche Lage der anfordernden Dienstinstanz und der ange- 
35 forderten Dienstinstanz innerhalb der beiden dargestellten 
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Steuerungssysteme ist zu der in FIG 3 bereits angegebenen 
ortlichen Lage identisch. 

5 Elne Client-Dienstinstanz und eine Server-Dienstinstanz 

sind in der Lage, Statusinf ormationen uber ihren Kommunika- 
tionsablauf zu speichern, da anderenfalls jeder Kommuni- 
kationsvorgang zwischen den beiden dutch einen erneuten 
Aufruf "Connect-Servlce" eingeleitet werden muQte. Es. kann 

10 nun Situationen geben, in denen zum Zeitpunkt eines Aus- 
falls Oder einer AuQerbetriebnahme der Server-Dienstin- 
stanz wegen einer Wartung die Kommunikationsbeziehung 
zwischen der Server-Dienstinstanz und der Client-Dienst- 
instanz noch bestehen kann. Versucht in einem solchen Fall 

15 die Client-Dienstinstanz einen weiteren Kommunikationsvor- 
gang, z.B. durch Senden von Meldungen zur Server-Dienst- 
instanz durchzufCihren, so erhalt sie von der inter-ProzeQ- 
Kommunikat ion eine entsprechende Fehlermeldung zuruck. 
Dies bedeutet, daQ die Kommunikationsbeziehung von seiten 
. 20 der Server-Dienstinstanz aufgelost worden ist. Die Client- 
Dienstinstanz muQ nun erneut eine Kommunikationsbeziehung 
mit einer geeigneten Server-Dienstinstanz aufbauen, um die 
Durchfuhrung des Dienstes f ortzusetzen. Die genannte 
Fehlermeldung der Inter-ProzeG-Kommunikation enthalt eine 

25 Angabe daruber, ob es sich um eine Nichtverfugbarkeit der 
Server-Dienstinstanz (wegen Wartung oder Uberlast) oder um 
einen Fehler des angesprochenen Puffers (z,B. wegen 
AbschluQ einer sanften AuQerbetriebnahme) handelt. 

30 im Falle eines sanften AuBerbetriebnehmens eines Dienst- 
leistungsmoduls wegen Erweiterung konnen alte bestehende 
Kommunikationsbeziehungen wahrend eines Uberspannungszeit- 
raumes erhalten bleiben, wahrend eine Client-Dienstinstanz 
zur Aufnahme einer erstmaligen Kommunikationsbeziehung 

35 durch den Aufruf "Connect-Service" auGer dem Kommunika- 

tionspfad als optionalen Parameter ein sogenanntes Erwei- 
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terungszeichen zuruckerhalt . Das genannte Erweiterungs- 
zeichen ist dann Tell des Nachrlchten-Headers jeder 
Nachrxcht In der inter-ProzeQ-Kommunlkation. Bei der 

5 genannten sanften Erwelterung sind wahrend des Erwei- 
terungszeitraums somit sowohl die alte Dienstinstanz 
als auch die neue Dienstinstanz verfugbar und das genannte 
Erweiterungszeichen wird benutzt, urn anzuzeigen, ob mit 
der alten Server-Dienstinstanz Oder der neuen Server- 

Q Dienstinstanz kommuniziert werden soil. 

Aus funktionaler Sicht kann unter den Diens tinstanzen zwi- 
schen vervielf altigten Dienstinstanzen eines Dienstes und 
parti tionierten Dienstinstanzen eines Dienstes unterschie- 

5 den werden. Vervielfaltigte Dienstinstanzen entstehen Je- 
wells durch die Vervielf altigung eines gesamten Dienstlei- 
stungsmoduls, Partitionierte Dienstinstanzen eines 
Dienstes weisen denselben Dienstschnittstellentyp wie 
vervielfaltigte Dienstinstanzen desselben Dienstes auf, 

0 fuhren den Dienst jedoch fur einen unterschiedlichen 

Bereich von Daten oder eine unterschiedliche Menge von 
Ressourcen durch (z.B. kann ein "File-Dienst" fur einen 
Halbleiterspeicher oder einen Magnetspeicher ausgefuhrt 
werden). Die Server-Dienstinstanzen weisen eine sog. 

5 Partitionskennung auf, urn zwischen partitionierten 
Dienstinstanzen unterscheiden zu konnen. 

Vervielfaltige Dienstinstanzen weisen denselben Dienst- 
schnittstellentyp auf und besitzen dieselbe Partitions- 

0 kennung, da sie den entsprechenden Dienst fur denselben 
Bereich von Daten oder dieselbe Menge von Ressourcen 
durchfuhren. Vervielfaltige Dienstinstanzen konnen auf 
unterschiedlichen Verarbei tungsplattf ormen vorhanden sein 
und eine identische Oder unterschiedliche Implementation 

5 aufweisen. Das Dienstemanagement benutzt fur die Auswahl 
einer Dienstinstanz einen bestimmten Auswahl-Algori thmus, 
der Lastzustande und Recoveryzustande der Verarbeitungs- 
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plattformen berCjcksichtigt , um eine optimale Lastvertei- 
lung und Fehlertoleranz zu unterstutzen. Diese Auswahl- 
Algorithmen sind fur die an f orderndenden Dienstinstanzen 
5 nicht sichtbar. Die Client-Oienstinstanz braucht somit 

zwischen mehreren vervielf alt igen Dienstinstanzen dessel- 
ben Dienstes nicht zu unterscheiden. 

Aus der Sichtweise der Programmiersprache handelt es sich 
10 bei einer Dienstschnittstelle um einen speziellen Daten- 

typ, durch den ein Oienst bzv*, genauer gesagt ein bestimm- 
ter Oiensttyp beschrieben wird. Der genannte Datentyp ent- 
halt u.a. eine vom Oiensttyp abhangige Sammlung von Remote- 
Referenzen (Remote-Prozedur-Auf ruf e RPC und Puffer), 
15 die im folgenden auch als Kommunikationspfad bezeichnet 

wird. Jede Deklaration einer Variable des Datentyps "Oienst- 
typ" entspricht der Erzeugung einer Dienstinstanz . Diese 
Erzeugung umfaQt die statische Initialisierung der 
genannten Remote-Ref erenzen . 



Eine Dienstinstanz ist innerhalb des Systems durch eine 
Diensttypkennung, eine Partitionskennung , eine Kapselken- 
nung und eine Oienstleistungsmodulkennung eindeutig spe- 
zifiziert. 



Die Diensttypkennung wird durch die Support-Software, 
genauer gesagt durch den sogenannten Systembinder (Linker) 
wahrend der Produktionszeit Oder Laufzeit des Systems 
erzeugt. Eine solche Diensttypkennung wird jeder dekla- 

30 rierten Dienstvariablen zugeordnet, Aufgrund der Zuordnung 
1st die deklarierte Dienstvariable nun innerhalb des 
Systems als Instanz eines bestimmten Dienstes bekannt. 
Alle Dienstinstanzen, deren Variablentyp (Oiensttyp) und 
Variablen-Name gleich ist, erhalten innerhalb des Systems 

35 dieselbe Diensttypkennung. Eine Instanz eines bestimmten 
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Dienstes kann seine Diensttypkennung niemals andern* 

Die Partitionskennung einer Diens t instanz wird ebenfalls 
5 zur Produktionszeit (statisches Bekanntmachen ) oder zur 

Laufzeit ( dynamisches Bekanntmachen) erzeugt. Der Typ der 
Partitionskennung ist ein Bereich von Oaten oder eine 
Menge von Ressourcen und wird innerhalb der ersten Kom- 
ponente des Oatentyps "Diensttyp" definiert. 

10 

Die Partitionskennung ermoglicht es der Anwender-Dienst - 
instanz zwischen mehreren Dienst instanzen zu unterschei- 
den. Alle Dienstinstanzen eines bestimmten Dienstes, die 
dieselbe Partitionskennung aufweisen, stellen aus der 
15 Sichtweise des Dienstemanagementsystems vervielf al tigte 

Dienstinstanzen dar. Alle Dienstinstanzen eines bestimmten 
Dienstes mit unterschiedlichen Parti tionskennungen stellen 
aus der Sichtweise des Dienstemanagementsystems partition- 
ierte Dienstinstanzen dar. 

20 

Es ist moglich, eine vorher zugeordnete Partitionskennung 
fur eine Dienstinstanz wahrend der Laufzeit zu andern. 
Dies ist allerdings nur fur solche Dienstinstanzen mog- 
lich, deren Zuordnung einer Partitionskennung auf 
25 dynamische Weise (dynamisches Bekanntmachen) erfolgt ist. 

Die Kapselkennung und die Dienstleistungsmodulkennung 
beschreiben die Lage einer Dienstinstanz innerhalb des 
gesamten Systems. Jede Dienstinstanz hat innerhalb des 

30 Systems somit eine eindeutige ortliche Lage. Es ist nicht 
erlaubt, dieselbe Instanz eines Dienstes innerhalb eines 
Dienstleistungsmoduls mehrmals zu erzeugen (Restriktion 
fur den Compiler). Es ist allerdings erlaubt, einer 
bestimmten Dienstinstanz eine zusatzliche Partitions- 

35 kennung zuzuordnen. Die genannte Restriktion bedeutet 
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also, da6 es nicht moglich ist, mehr als eine Dienstin- 
stanz eines bestimmten Dienstes innerhalb elnes bestimmten 
Dienstleistungsmoduls 2u haben* 

Die Dienstleistungsmodulkennung wird durch den Linker 
erzeugt und dem of f-line-Systembauer ubergeben. Die 
Kapselkennung wird dutch den of f-line-Systembauer erzeugt. 
Die Kapselkennung und die Dienstleistungsmodulkennung 
werden vom of f-line-Systembauer zum on-line-Systembauer . in 
Form von Tabellen ubergeben. Diese Tabellen werden vom 
on-line-Systembauer benutzt, wenn er eine sogenannte 
Dienstetabelle erzeugt^ 

Jede Dienstinstanz hat innerhalb des Systems eine eindeu- 
tige ortliche Lage. Diese ortliche Lage wird durch eine 
Grtskennung (Kapselkennung und Dienstleistungsmodul- 
kennung) beschrieben. Das Dienstemanagement erlaubt es , 
dafl mehrere Dienstinstanzen eines bestimmten Dienstes, 
doho eines bestimmten Diens tschnittstellentyps dieselbe 
Grtskennung besitzen, solange sie nicht dieselbe Parti- 
tionskennung aufweisen* 

Eine Dienstinstanz kann durch einen Remote-Prozedur-Auf- 
ruf RPC Oder eine fsJachricht (Cast) in einem der Puffer der 
genannten Dienstinstanz angerufen werdeno Der Anruf einer 
Dienstinstanz eines bestimmten Dienstes uber die Grenzen 
einer Dienstleistungskapsel hinaus ist durch ein entspre- 
chendes Feld von Remote-Ref erenzen (Puf fer-Ref erenzen und 
RPC-Referenzen) und den Gebrauch von entsprechenden Kommu- 
nikationseinrichtungen des Betriebssystems implementiert « 
Der Anruf einer Instanz eines bestimmten Dienstes inner- 
halb einer Dienstleistungskapsel ist durch den Gebrauch 
eines Feldes auf Local-Ref erenzen (Zeiger auf Puffer und 
Prozeduren) implementiert • Die GroQe eines solchen Feldes 
hangt von der Anzahl der Komponenten eines Dienstes ab. 
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Die Aufgabe des Dienstemanagementsystems ist es aufgrund 
einer Anforderung eines Dienstes eine entsprechende 
Dienstinstanz zur Durchfuhrung des angef orderten Dienstes 
5 auszuwahlen und deren Kommunikat ionspfad (Feld von Refe- 
renzen) der anfordernden Dienstinstanz zu ubergeben. Die 
genannte Anforderung eines Dienstes wird mit Hilfe des 
Betriebssystem-Aufruf s "Connect Service" bewirkt. Der ge- 
nannte Betriebssystem-Auf ruf ermittelt den genannten 

10 Kommunikationspfad, indem er in verschiedenen Tabellen 

nachsieht. Die in diesem Zusammenhang wichtigsten Tabellen 
sind eine statische Oienstetabelle und eine transiente 
Dienstetabelle. Die Elemente dieser Tabellen sind die 
Dienstkennungen, die Kapselkennungen , die Diens tleistungs- 

15 modulkennungen, die Parti tionskennungen und schlieQlich 
die Kommunikationspfade. 

Die Diensttypkennung ist als ein Parameter innerhalb des 
Betriebssystems-Aufrufs "Connect Service" unbedingt notig. 

20 Andere Parameter, wie z.B. die Part itionskennung oder 

die Kennungen bezuglich der ortlichen Lage ( Kapselkennung 
und Dienstleistungsmodulkennung) sind optionale Parameter. 
Wenn der genannte Betriebssystem-Aufruf erfolgreich ist, 
wird - wie bereits erwahnt - ein Datenfeld mit Remote- 

25 Referenzen (Kommunikationspfad), der aufrufenden 
Dienstinstanz zuruckgegeben . 

Das Dienstemanagementsystem benutzt zur Durchfuhrung 
seiner Aufgabe die genannten Diensttabellen , welche 

30 Informationen uber die verfugbaren Dienste des Systems, 
die zur Durchfuhrung der Dienste vorhandenen Dienstin- 
stanzen und die zu den Dienstinstanzen zugehorigen Kommu- 
nikatispfade beinhalten. Diese Diensttabellen werden 
durch werkzeuge (Tools) der Support-Software erzeugt, die 

35 sowohl off-line als auch on-line arbeiten. 
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Die erzeugten Oiensttabellen enthalten Informationen uber 
die verschiedenen Verarbeitungsplatt f ormen des Steuerungs- 
systems und die verfugbaren Oienstlnstanzen auf den vor- 
5 handenen Verarbeitungsplattf ormen. 

Insbesondere die Ortskennungen werden durch ein On-Line- 
Werkzeug erzeugt. Die Ortskennungen werden von der Inter- 
Prozess-Kommunikation und der Inter-Prozessor-Kommunika- 

10 tion des Betriebssystems benutzt. Das Dienstemanagement- 
system macht keine weiteren Annahmen uber die erzeugten 
Ortskennungen. Es geht davon aus, dafi die erzeugten Orts- 
kennungen gultig sind und bietet der Inter-Prozess-Kommu- 
nikation, der Inter-Prozessor-Kommunikation und dem inter- 

15 nen Tr ansportprotokoll anhand der Ortskennungen die von 

diesen Systemen benotigten Informationen uber die Zielbe- 
stimmungen an. 

urn die genannten Oiensttabellen zu erzeugen, ist eine 
20 informationsweitergabe uber verschiedene Werkzeuge der 

Support-Software notwenig, die im folgenden naher erlau- 
tert wird. 

Der Compiler erkennt bei der Compilierung zunachst die 
25 Deklarationen von Dienstvariablen (Oienstlnstanzen) und 
deren Schnittstellenkomponenten (Puffer etc.) innerhalb 
des Source-Codes. Der Compiler reicht diese Information an 
den Linker welter. Nach der Compilierung sind die genann- 
ten Oienstlnstanzen einem bestimmten Dienstleistungsmodul- 
30 typ zugeordnet. 

Der Linker reicht sodann die genannten Informationen an 
den off-line Systembauer weiter. Nach dem Binden durch 
den Linker gehoren die genannten Oienstlnstanzen zu einem 
35 bestimmten Dienstleistungskapseltyp . Die Oienstleistungs- 
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modulkennung, die die relative Lage des Dienstleistungs- 
moduls innerhalb elner Dienstlelstungskapsel angibt, ist 
zu diesem Zeitpunkt festgelegt worden. AuQerdem ist zu 
5 diesem Zeitpunkt auch die relative Position der Kompo- 
nenten der Schni ttstellen der Dienstinstanzen innerhalb 
einer Dienstlelstungskapsel festgelegt worden. 

Der of f-line-Systembauer ordnet nun den vom Linker iiber- 
10 reichten Dienstinstanzen entsprechende Oienstkennungen zu. 
Au3erdem erzeugt er fur jede Verarbeitungsplattform einen 
bestimmten Ladungstyp, durch den jeweils die Funktion 
einer Verarbeitungsplattform bestimmt wird. Die relative 
Position einer Dienstlelstungskapsel innerhalb eines 
15 Ladungstyps ist nun festgelegt. 

Der on-line-Systembauer kennt die vom of f-line-Systembauer 
erzeugte Konf iguration der Hardware und der zugehorigen 
Ladungstypen der verarbeitungsplattf ormen. Er erzeugt da- 

20 raus die notwendigen Tabellen fur das Dienstmanagementsy- 
stem. Er kennt die Beziehungen zwischen den Ladungstypen 
und den spezifischen Ortskennungen einer verarbeitungs- 
plattform. Die von ihm erzeugte Dienstetabelle enthalt die 
Beziehungen zwischen Dienstinstanzen, deren ortlicher Lage 

25 und deren zugehorigen Schnittstellenkomponenten. 

FIG 5 zeigt den Gebrauch der Dienstetabelle durch das 
Dienstemanagement system. 

30 Das Dienstemanagementsystem DMS enthalt gemaO FIG 5 zur 

Durchfuhrung seiner Aufgabe eine Dienstetabelle ST, in der 
die Schnittstellen von Instanzen bereits bekanntgemachter 
Oiensttypen abgespeichert sind. Immer wenn eine Dienstin- 
stanz einen Dienst von einem anderen Diensleistungsmodul 

35 anfordern will und noch keine Kommunikationsbeziehung zu 
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einer entsprechenden Dienstinstanz besteht, ubergibt es an 
das Dienstemanagementsystem den Namen des angef orderten 
Oiensttyps, z.B. den Namen "Oienst 1". Oas Dienste- 
5 managementsystem beinhaltet die Namen der bereits bekannt- 
gemachten Dienste (Diensttypen ) in einer Dienstenamens- 
tabelle innerhalb der Dienstetabelle ST, sowie in einer 
Instanzentabelie die Or tskennungen und Partitionskennungen 
derjenigen Dienstinstanzen, die den genannten Oienst aus- 

10 fuhren. Anhand des vom anfordernden Dienstleistungsmodul 
ubergebenen Namens kann das Dienstemanagementsystem somit 
aus den moglichen Diens tleistungsmoduln das hinsichtlich 
einer optimalen Lastverteilung am besten geeignete Dienst- 
leistungsmodul, das den angef orderten Oienst beinhaltet, 

15 auswahlen und dem anfordernden Dienst den entsprechenden 
Kommunikationspfad zu einer Dienstinstanz des angefor- 
derten Dienstes ubergeben. Die anfordernde Dienstinstanz 
kann nun die Kommunikation mit der zugehorigen Dienstin- 
stanz aufnehmen. 

20 

Anstelle einer bloSen Namensangabe des angef orderten Dien- 
stes kann der anfordernde Dienst auch zusatzliche Auswahl- 
kriterien angeben, z.B. die Angabe eines bestimmten Steue- 
rungsprozessors, die Angabe einer bestimmten Instanz eines 
25 bestimmten Dienstes oder einer bestimmten Dienstleistungs- 
kapsel . 

Ein bestimmter Dienst, z.B." Dienst 1" ist von mehreren 
verschiedenen Instanzen durchfuhrbar . Jede Instanz fiihrt 
30 den Dienst jedoch nur fur einen bestimmten Bereich von 

Oaten oder eine bestimmte Menge von Ressourcen durch. Oie- 
ser Umstand wird durch eine Partitionskennung IDp 
markiert . 

35 In FIG 5 sind drei Dienstleistungsmodule, namlich SPUl, 
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SPU2 und SPU3 in das System eingebracht worden, wobei 
es sich bel den Dienstlelstungsmoduln SPUl und SPU2 um 
identische Dienstleistungsmodule handelt und somit wenig- 
5 stens eines von den beiden genannten Dienstlelstungsmoduln 
durch vervielfaltigung entstanden ist. Aufgrund der Iden- 
titat der beiden Dienstlelstungsmoduln besitzen einander 
entsprechende Oienste der beiden Dienstlelstungsmoduln, 
2.B. "Dienst 1", auch dieselben Parti tionskennungen IDp, 

10 

Nach dem Einbringen eines Dienstleistungsmoduls in das 
System, sei es durch Laden Oder Vervielf al t igen , erfolgt 
das Bekanntmachen der Dienste des neu eingebrachten Dienst- 
leistungsmoduls gegenuber dem Di ens temanagement system 
15 DMS, dessen Ablauf nun naher beschrieben wird. 

In einem ersten Schritt wird aufgrund einer Anforderung 
"Announce Service", die von einer anfordernden Instanz an 
das Dienstemanagementsystem gestellt wird, die Ortskennung 
20 (Kapselkennung und Dienst leistungsmodulkennung ) aus dem 
ProzeOkontrollblock der aufrufenden Instanz entnommen. 

Die Oiensttypkennung und die Parti tionskennung werden als 
Parameter in der Anforderung "Announce Service" mitiiber- 

25 geben. Fur Dienste, die dynamisch, d*h. zur Laufzeit des 
Systems bekanntgegeben werden, steht in jedem Dienstlei- 
stungsmodul ein separator ProzeQ zur Verfugung, der 
Jewells nur Dienste seines eigenen Dienstleistungsmoduls 
anmelden kann. Der genannte ProzeS kann pro Dienstinstanz 

30 mehrere Partitionskennungen anmelden. 

In einem zweiten Schritt wirft das Dienstemanagement nun 
anhand der ubergebenen Oiensttypkennung und der 
Ortskennung einen Blick in die bezuglich des Diensttyps 
35 relevante Instanzentabelle innerhalb der Dienstetabelle. 



3NSOOCIO: <DE_9300S62UlJ_> 




Wenn die in der Anforderung ubergebene Partitionskennung 
in der Instanzentabelle bereits definiert ist, geschieht 
nichts und es wird ein entsprechender Ruckgabewert der 
5 aufrufenden Instanz zurijckgegeben, Wenn in der genannten 
Instanzentabelle jedoch keine korrespondierende 
Dienstinstanz mit derselben Partitionskennung gefunden 
wird, wird die Anforderung ausgefuhrt, d.h. die neue 
Partitionskennung wird in die Partitionsliste innerhalb 
10 der Instanzentabelle eingetragen und daraufhin der die 
Bekanntmachung anfordernden Instanz ein entsprechender 
Ruckgabewert zuruckgegeben • 

In einem dritten Schritt muQ die soeben innerhalb einer 
15 bestimmten Verarbeitungsplatt form erfolgte Bekannt- 

machung einer Dienstinstanz auch auf die ubrigen Ver- 
arbeitungsplatt formen verteilt werden. Die Bekannt- 
machungsinformationen der neuen Dienstinstanz mussen dazu 
zunachst in einer lokalen Zwischenspeichertabelle abge- 
20 speichert werden, bevor sie nach einer angemessenen Zeit- 
spanne durch eine Multicast-Kommunikation zu den Dienste- 
managementsystemen der anderen Verarbeltungsplattf ormen 
gesandt werden. Wenn die genannte lokale Zwischenspeiche- 
rungstabelle bereits vor der genannten angemessenen Zeit- 
25 spanne einen bestimmten Anfullungsgrad uberschri tten haben 
sollte, wird ebenfalls eine Multicast-Kommunikation auf 
Betriebssystemebene ausgelSst. 



Zu dem soebenen beschriebenen Vorgang des Bekanntmachens 
30 einer neuen Dienstinstanz innerhalb des Steuerungssystems 
existiert ein umgekehrter Vorgang zum Loschen der Be- 
kanntmachung einer neuen Dienstinstanz. Dieser umgekehrte 
Vorgang wird durch den Betriebssystemauf ruf "Withdraw 
Service" ausgelost und in analoger Weise zu dem vor- 
35 her erlauterten Vorgang des Bekanntmachens durchgefuhrt . 
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Schutzansp ruche 



!• Steuerungssystem eines Vermittlungssystems mit 
a) wenigstens einem Steuerungsprozessor 
^ b) Jewells elnem Betrlebssy stem pro Steuerungsprozes- 

sor, das die Betrlebsmlttel des Vermittlungssystems 
steuert, verwaltet und uberwacht, 

c) wenigstens elnem Dlenstlelstungsmodul (SPU) pro 
Steuerungsprozessor, das Jewells wenigstens elnen 
Dlenst belnhaltet, das auf mehreren Steuerungspro- 
zessoren und/oder mehrmals auf elnem Steuerungspro- 
zessor elngebracht seln kann und das zur Ausfuhrung 
elnes seiner Dlenste elnen Dlenst elnes anderen 
Dlenstlelstungsmodul anfordern kann, 

d) elnem Dlenstemanagement system , das Jewells Im 
Betriebssystem enthalten 1st und das elnem Dlenst- 
lelstungsmodul, das elnen bestimmten Dlenst 
anfordert, den Kommunlkationspf ad mittellt, uber den 
die Kommunlkatlon zu einem ausgewahlten Dlenstlel- 
stungsmodul aufgenommen werden kann, das den ange- 
forderten Dlenst belnhaltet. 



2. Steuerungssystem nach Anspruch 1, 
dadurch gekennzeichnet, 

daQ ein Dlenstlelstungsmodul auf mehreren Steuerungsprozes- 
soren und/oder mehrmals auf elnem Steuerungsprozessor in 
das Steuerungssystem einbrlngbar ist, ohne den Betrleb der 
Steuerungsprozessor en zu unterbrechen • 

3. Steuerungssystem nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

daQ ein eingebrachtes Dlenstlelstungsmodul auf mehreren 
Steuerungsprozessoren und/oder mehrmals auf elnem 
Steuerungsprozessor vervlelf altlgbar 1st, ohne den Betrleb 
der Steuerungsprozessoren zu unterbrechen. 
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4. Steuerungssystem nach einem der Anspruche 1 bis 3, 
dadurch gekennzeichnet, 

daB das Dienstemanagementsystem die Auswahl eines Dienst- 
5 leitungsmoduls fur einen angef orderten Dienst in Abhangig 
keit der Lastzustande der Steuerungsprozessoren durch- 
fuhrt* 

5. Steuerungssystem nach einem der Anspruche 1 bis A, 
10 dadurch gekennzeichnet, 

daS die Dienstleistungsmoduln die Kommunikation uber den 
genannten Kommunikationspf ad durch Senden von Meldungen 
realisieren, 

15 6. Steuerungssystem nach nach einem der Anspruche 1 bis A 
dadurch gekennzeichnet, 
daS die Dienstleistungsmoduln die Kommunikation uber den 
genannten Kommunikationspf ad durch Aufrufen von Remote- 
Pro zeduren realisieren . 

20 

7. Steuerungssystem nach einem der Anspruche 1 bis 6, 

dadurch gekennzeichnet, 

daS 

a) mehrere Dienstleistungsmoduln zu einer Dienstleistungs- 
25 kapsel zusammengefaQt sind, 

b) einer Dienstleistungskapsel jeweils ein bestimmtes 
Budget an Betriebsmitteln zugeordnet ist. 



30 



35 
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